I ran flake8 after the functional changes, but not after adding the tests =|

Depending on merge order, affects #1621

I'm lukewarm on this one. Increasing the complexity of our getter functions and adding an optional argument for the few cases where a falsy value is meaningfully different from the default seems like overkill. Those cases are free to use the explicit pattern you described, or the slightly more concise:

v = get_x_value(*args)
value = v if v is not None else 'default'

Plugins that need to retrieve the same value with the same default in several places are better off defining an internal getter-wrapper, anyway, regardless of whether its body contains one (with this patch) or two (without this patch) lines of statements. (Potential bias note: A few of my IRC games use this model, so I can handle all the default fallbacks and other value validation in a single place, before returning a value to the code that needs it. So I'm used to doing things this way anyway.)

My potential bias aside, I believe that in the vast majority of cases, value = get_x_value(*args) or 'default' works just fine (but admittedly, I have not conducted an empirical study of existing plugins in the wild). The code here looks fine, though, so it's probably merge-ready if I change my mind (and/or am convinced to).

The tradeoff is four lines and an optional argument in Sopel, or boilerplate in many plugins using the DB to handle defaulting. I can't imagine it's an uncommon need since every one of my nontrivial plugins would benefit, so I would rather the mild increased complexity be in the library than in every implementation.

Poking quickly through the builtin modules:

• pronouns.py needs more complex logic
• safety.py needs more complex logic
• seen.py needs more complex logic, I think
• reddit.py directly uses None as falsy
• clock.py could drop 3-4 lines
• adminchannel.py could drop 2 lines

So of the 11 plugins I've looked at that use the DB, 7 of them would benefit (and obviously none would be harmed). If you would like me to make those changes to clock and adminchannel, this PR's non-test changes could reduce the project's line count =p

@half-duplex Would you add commits updating the relevant plugins to use the new argument? I think I'm coming around on this, and it'd be good to have everything updated (in core) at once.

Also, by the project's general FIFO merge order, #1621 will be merged first. So plan to rebase and add this same functionality to plugin values. (You might or might not have luck rebasing directly onto that PR's branch, if you want to get the rebase done ASAP. GitHub can be unpredictable regarding how it handles duplicated commits when PRs get merged.)

#1621 is merged. Update when ready. 😸